Application/Service data as downloaded in a browser or application session is transported by means of an Internet Protocol (IP) packet stream. This IP packet stream can be based on either Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). TCP is a connection oriented protocol which has a setup and teardown procedure. Once a TCP connection is established an application protocol, such as Hypertext Transfer Protocol (HTTP) may be used on top to transfer the data and when the application is finished with the data transfer the TCP connection can be released. A TCP connection is thus one type of application communication connection and UDP another type of application communication connection.
TCP connections can either be persistent, an application keeping a constant connection to a server to fetch or send new data whenever need arises, or the TCP connection can be non-persistent in which case the TCP connection is released whenever there is no data immediate to transfer, once the need arises again a new TCP connection is setup.
Processing and latency may be saved if the connection is persistent; depending on application behavior e.g. intermittent data exchanged between one and the same server during a long time. The value of persistency is less if data is continuously exchanged with different servers.
It is well known that connection persistency is very valuable when a high number of data items should be collected from the same server; the persistency will here remove the phenomena of TCP slow start for all the subsequent items, this given that the data items are fetched from the server back to back with no or very small interruptions in between.
Usually there is little cost for a client to maintain a persistent connection, a certain amount of memory for state and buffers but no processing is associated with the persistency. On the server side of the connection the persistency can be more of an issue since many clients are connected to the same server and the memory associated with the persistent connections need to be balanced with the processing cost of setting up and tearing down TCP connections with same client over and over again. Different server setups will have different strategies.
Usually the decision to maintain or tear down a connection can be taken very dynamically, irrespectively of when a decision is taken the cost associated with the release (exchange of data on an IP network to negotiate the release) is the same; there is no time dependency in the cost.
In particular each end of the connection can maintain its own strategies and release the connection whenever its own set of criteria is fulfilled.
The common strategy by both the client and the server is to release the TCP a fixed set of seconds (timer) after the last transmission on the connection. If something is sent before the expiry of the timer, the timer is restarted and the same fixed time is re-applied. A server may also choose to maintain connections for as long as it has the resources and then release connections when resources are exhausted.
In a radio access network where there is a time dependency in transport/power consumption/load cost it is not obvious that the handling of the IP connection can be totally independent of the state of the underlying radio access network. Depending on state in the radio access network the transmission of user data will have different cost.
It is also usually so that the state of the radio access network is not known to both ends of the connection. In particular the server side of the connection is usually unaware of the current state of the radio network.
In a Wideband Code Division Multiple Access (WCDMA) system the exact state behaviour of the radio access network will depend on a number of entities, timers and strategies used by the cellular network operator and also timers and strategies used by the device vendor. In particular there are a number of timers in the cellular network: T1 inactivity to transition from Dedicated Channel (DCH) to Forward Access Channel (FACH) and T2 inactivity to transition from FACH to URA (UTRAN Registration Area) Paging Channel/Cell Paging Channel/Idle (URA_PCH/CELL_PCH/Idle). There is also a device initiated state transition from DCH/FACH to URA_PCH/CELL_PCH/Idle called Fast Dormancy. Today these transitions are executed without coordination with TCP releases.
Usually it is the behaviour of the user data flow that will control in which state the radio access network will be in, but the exact transition times and strategies used will vary among the networks and can also have a time variance due to different traffic load etc.
In a situation as above it is for example costly to have the server side terminate an IP connection since the release of the connection can happen in a radio network state where the device need to be paged, the device has no assigned physical channel and the system need to broadcast a request to re-establish the physical channel.
There is therefore a need for an improvement in the way application communication connections are released.